home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
pc_board
/
rnet108u.zip
/
RNET.DOC
< prev
next >
Wrap
Text File
|
1992-07-27
|
73KB
|
1,430 lines
RNET.DOC Page 1
╓──────┐ ╓────┐╓─┐ ╓─────┐ ╓─────┐
║ ╒══╗ │ ║ ╒╗ │║ │ ║ ╒═══╛ ╚═╗ ╒═╛ Version: 1.08
║ └──╜ │ ║ │║ │║ │ ║ └─┐ ║ │ Release: Mon Jul 27 1992
║ ╒═╗ ╒╛ ║ │║ │║ │ ║ ╒═╛ ║ │
║ │ ║ └┐ ║ │║ └╜ │ ║ └───┐ ║ │ Copyright 1989-92 Robert Vostreys
╚═╛ ╚══╛ ╚═╛╚════╛ ╚═════╛ ╚═╛ All Rights Reserved
PCBoard 14.x EchoConference driver for "QWK" packet based EchoNetworks.
_____________________________Naming Conventions____________________________
RNet is distributed using the filenaming convention of: RNETvvvx.zzz.
VVV refers to the version, such as '106' for version 1.06, '200' for
version 2.00. The X refers to a letter code specifying alpha, beta,
registered, and shareware release versions. Alpha and beta versions of
RNet begin at 'A' and continue no further than 'P'. The registered release
version is distributed as RNETvvvR.zzz, the shareware release version is
distributed as RNETvvvU.zzz ('U' for unregistered). The final ZZZ refers
to the compression utility extension, which will usually be .ARC or .ZIP or
whatever. When referring to this distribution file in the documentation,
it will usually be referred to as "ZIP file."
_____________________________Distribution File_____________________________
The following files should be present within the distribution ZIP file:
RNET.EXE Main executable program
RNET.DOC The documentation you are currently reading (RTFM!)
RNET_REF.DOC Quick reference for RNet configuration and operation
REGISTER.DOC Shareware registration form and information
CHANGES.vvv Changes from version to version (history files)
ECHOS.DOC Description and information about EchoConferencing
MESSAGES.DOC Listing of errors which are not otherwise explained
RNETCONF.DOC Information on PCBCONF and PROCONF interfacing
PCBCONF.EXE Interface utility for PCBoard CNAMES conferences
PROCONF.EXE Interface utility for ProDoor CONFINFO conferences
SAMPLE1.CFG Sample (verbose) configuration file with comments
SAMPLE2.CFG Sample (brief) HOST_ID.CFG configuration file
MAILRUN.BAT Example BAT for making a host mail transfer
MAILRUN.SLT Example Telix SALT for host mail transfers
PCBLOGIN.SLT Example Telix SALT to login to host and open maildoor
LOWMEM.BAT Example BAT for using external compression
RNET.DOC Page 2
Alpha/Beta versions usually do not include the .DOC files but instead
include the CHANGES.vvv file for that version. Please be sure to read this
file if you are working with an alpha or beta version of RNet!
_____________________________Distribution Rules____________________________
Sysops MAY place 'ZIP Comments' on the RNet distribution ZIP file if they
normally do such with all their download files.
Sysops MAY NOT place additional files (such as 'README.1ST' or 'BBS_AD')
within the distribution ZIP file nor may they use the PKZIP -AV
verification stamp.
Distribution of the alpha, beta, and registered versions is restricted to
those systems with specific permission to distribute such. Do not
distribute any version of RNet except the unregistered (RNETxxxU) version!
RNET.DOC Page 3
___________________________Contacting the Author___________________________
Problems, questions, and suggestions should be directed to Robert Vostreys:
Modem: Faster-Than-Light BBS
Node1: 404-292-8761 [300 to 14400 V32/bis]
Node2: 404-299-3930 [300 to 14400 USR HST]
US Mail: Robert Vostreys, FTL Sysop
Post Office Box 2315
Stone Mountain, GA 30086-2315
EchoMail: ILink: Sysops, MM-RNet, or Admin EchoConferences.
SmartNet: Sysops, MarkMail, or Admin EchoConferences.
RIME: Sysops or Admin EchoConferences (route ->FTL).
Atlanta: AtlSysops or NetLANTA EchoConferences.
GEnie: R.Vostreys
_________________________________Shareware_________________________________
Since you have likely read statements under the heading "Shareware" often,
I'll not bother going into the idea again. Simply be aware that RNet is
shareware ($20US suggested), the registered version has some additional
features, and that the file REGISTER.DOC contains the shareware
registration form and information.
Any and all registered users may download and operate any later 1.xx
registered and beta versions of RNet as desired. The registered and beta
versions are always available from:
Faster-Than-Light 404-292-8761 / 299-3930
The Right Place<tm> 404-276-2607 / 476-0847
RNET.DOC Page 4
__________________________________Overview_________________________________
RNet is a utility to transfer messages from one BBS to another using the
QWK packet format. The transfer/sharing of messages between BBS's is
commonly referred to as "EchoMail", "NetMail", or "EchoConferencing." For
more information on echo network design and the terms used within this
document, see ECHOS.DOC.
RNet will insert QWK packet messages into your PCBoard 14.x messagebases
and export new messages in a REP packet for insertion into a host system's
messagebases. If you are familiar with the operation of EZ-Reader, Deluxe,
AmigaReader or similar QWK packet offline readers, most of the terms and
ideas used here will be familiar.
The actual transfer of QWK/REP packets is left up to you and your choice of
communications programs. Canned scripts and programs such as RoboComm will
work well to automate mail transfers. A working example of a Telix SALT
script (MAILRUN.SLT) is included for your use and information.
Usually, RNet is used in a system "event" to process incoming and outgoing
mail to a network host during the night (when long distance carrier rates
are lower). RNet is designed to be extremely dependable, which may
substitute safety at the expense of speed.
While RNet is for use with PCBoard 14.x (or ProDoor/ProBBS), your host need
not be running a PCBoard system. TomCat! is an example of a WildCat! door
and MarkMail is an example of a PCBoard/ProDoor door.
RNet is designed to be very verbose (both on-screen, error/warning reports,
report generation options, callerlog reporting in two formats), and even
shows on the Node Chat display when running. If something goes wrong or
if a condition exists(ed) that warrants attention, a log entry will be made
to ERROR.LOG with any other information you might need. There are a
variety of reports and logs that can be produced as desired.
RNET.DOC Page 5
________________________________Feature List_______________________________
Support for most (all?) QWK packet mail doors that support NetStatus.
Limited to 32,765 conferences _per_ configuration / host QWK packet.
Limited to 32,765 conferences _per_ CNAMES or CONFINFO file (or create your
own conference location file (RNETCONF) using a text editor for complete
control.)
You may have an unlimited number of hosts and configuration files.
Complete multi-node concurrent access to local conferences supported -- you
will never lose a message due to concurrent messagebase insertions, even if
running RNet on several nodes concurrently importing into the same
messagebases. Includes support for the new PCBoard 14.5 DOS 3.1 record
locking method.
Support for PCBoard 14.x CNAMES (39 and 65534 conference versions) and
ProDoor CONFINFO (255 and 2040 conference versions).
Always sends Host Sysop their private (R/O) messages. Always imports
private messages addressed to the Local Sysop. This allows you and your
host to have a private conversation even in public-transfer-only
conferences/networks.
Support for multiple hosts (using the same messagebases) with or without
cross echoing as desired. This is useful for gateway connections between
two or more networks.
Private (R/O) messages can be passed or limited on a global or conference-
by-conference basis.
You may choose to honor or ignore the PCBoard 14.x "ECHO" flag.
Completely definable tagline. The registered version of RNet allows you to
define the ENTIRE tagline (no software "id" involved -- what you define is
what you get!)
A separate text-editable pointer file is maintained for each host. Pointer
files are automatically backed up when a new REP packet is created.
Special "Network Sysop" functions are supported to allow the network
administration to route very important messages to your MAIN BOARD if
needing such attention.
Writes logs and pointer files to the drive/directory where the
configuration file is found. This allows you to execute RNet from wherever
is convenient for your particular system configuration.
Local display (processing screen) supports 25/43/50/60 line modes.
Conference usage analysis reports showing activity in network conferences
and percentage of traffic generated locally.
Message filtering: RNet will expand TABs, strip unneeded spaces, remove
bells/^S/^X, pack blank lines from taglines, and even decrypt John Hancock
encrypted taglines if desired.
RNET.DOC Page 6
Handles and reports bad or corrupted PCBoard messagebases and NDX files.
Automatically builds a pointer file for each host. If you add a
conference, you need not reset a pointer as RNet will assume you want to
start at the high message number.
Intelligent pointer handling. If a pointer is set to a message lower than
the lowest message, RNet will reset the pointer to the low message. If a
pointer is set above the high message, RNet will reset the pointer to the
high message. You may safely change pointers to any value if needed (such
as to force export of an entire messagebase for a crashed host or to make a
backup).
Warns you if you receive a conference in a QWK packet that you have not yet
configured on your end.
Special commandline operations to force RNet to import/export only a single
specific conference or to "continue" importing in a QWK packet that stopped
for some reason (such as disk full). No need to reprocess the entire
packet insertion!
Automatic appending of messages to the REP packet if a REP packet is found
present when running an export. This is can be enabled and is suggested
since it allows you to continue "building" on a REP even if your host is
busy or down.
TCANNING of messages to/from specific users. You can even TCAN messages
that are "from" a user, but not those "to" that user and/or vice-versa.
Users (and the Sysop for that matter) can "watch" RNet's operation on the
Node Chat display in PCBoard. RNet looks like a normal "user". The "City"
display is used to relay what RNet is specifically doing at that time.
Option to delete QWK packets after successful import automatically. If an
import is unsuccessful, RNet will leave the QWK packet there for your
further investigation.
Networks which support NETNEWS type conferences have a much easier time
with RNet. RNet can automatically copy messages in special conferences
(such as Administration level conferences) into a NetNews conference.
Also, special messages (from a specific name/person, with a specific
keyword/subject) can be posted in the NetNews and transferred out along the
Administration level conferences. This keeps ALL chitchat out of NetNews
style conferences.
Automatic processing of multiple QWK packets (such as *.QWK, *.QW0,.. up to
*.QW9). Useful if using a "pre-built" packet door such as QMail 4.xx which
may result in your downloading multiple packets for RNet to process.
Automatic import speed determination. RNet watches what other users are
doing via the USERNET.DAT file to decide how safe it is to import messages
quickly or safely. If someone on another node (even another RNet) is
entering a message, RNet will flush the DOS directory structure after each
message for safety in importing messages. Otherwise, RNet flushes after
each conference is completed. SAFETY FIRST!
RNET.DOC Page 7
_________________________________NetStatus_________________________________
NetStatus refers to your having the "permission" of a host system to echo a
messagebase (or bases). You might have NetStatus on perhaps only one or
two conferences of that particular host's conferences -- that is up to the
discretion of your host.
The host Sysop _must_ enable NetStatus for you before you can transfer any
messages back and forth! Usually this is done with your being accepted
into an echo network such as ILink or SmartNet, or it may simply be that
you and another sysop wish to echo (transfer) a debate conference between
your boards. Your host must enable NetStatus for your user record within
the maildoor you will be using for echoing messages.
If you do not have NetStatus, RNet will write a log entry to ERROR.LOG and
skip the conference(s) in question. If you are setting up for echomail and
do not yet have NetStatus on the host system, you will not be permitted to
import messages from the host system. Exporting of messages with RNet will
correctly create a REP file, but they will not be accepted on the host
without NetStatus enabled.
_________________________________MailDoors_________________________________
For RNet to process messages to/from a host system your host must support a
QWK packet format mail door. This is where you will download QWK packets
(which contain new messages coming from the host/upper network) and upload
your REP packets (containing messages from your system/lower network).
Each BBS running a mail door is assigned a HOST_ID. If your host was, for
example, "Faster-Than-Light BBS", the assigned HOST_ID might be "FTL".
Ask your host what the HOST_ID is if not obvious from within the mail door.
When you request new messages from your host's mail door, a HOST_ID.QWK
packet will be constructed with new messages. Using the above example, the
packet would be called FTL.QWK.
When RNet collects new messages from your system to be sent up to the host,
it will create a HOST_ID.REP packet, such as FTL.REP.
Different mail doors support different maximum conferences for echomail.
These limitations are for the number of conferences the HOST can support,
not how many conferences you might wish to have. RNet always supports up
to 32765 conferences _per_ RNETCONF configuration on your system! Host
conference support by door (as of November 1990):
KMail v1.xx Up to 32765 conferences available on the host system.
MarkMail v1.xx ' 256 '' '' ''
MarkMail v2.xx ' 32765 '' '' ''
QMail v2.xx ' 128 '' '' ''
QMail v3 & 4.xx ' 256 '' '' ''
QMail v4(beta) ' 2048? '' '' ''
TomCat! v1.xx ' 256 '' '' ''
RNET.DOC Page 8
______________________________Echo Conferences_____________________________
Echo conferences are the same as any normal conference on your board except
that the EchoFlag is used/supported. In PCBSM/PROSM, create a conference
as normal. Then, under the field asking about "Echo mail in conference",
specify YES. Beyond that single difference, an Echo conference is the same
as any other (in setup that is).
Be sure you specify enough "Index (NDX) blocks" to handle the inflow of
network message traffic. If you pack your messagebases often (daily or
perhaps weekly), you can probably get away with one or two blocks. If, on
the other hand, you want to keep a large number of messages on-hand or if
the traffic is extremely heavy (as with most debate conferences), you will
more than likely want to use four or perhaps six blocks. Larger values
waste space unless you intend to keep 10,000 messages in a given conference
concurrently (or if you never pack the messagebases).
Normally, messages entered in an Echo conference will not be echoed (send
out over the network) without the EchoFlag turned on. When a user enters a
message, they will be prompted "Echo this message?" If they specify YES,
then the message will be echoed. If they specify No, then the message will
remain on the local system only. Note that this can be overridden with the
"IGNOREECHO=" keyword in the HOST_ID configuration file.
________________________________Commandline________________________________
RNet needs only simple information on the commandline to operate. Most of
the information RNet needs is derived from the HOST_ID.CFG configuration
file. You need only tell RNet what kind of operation you want it to do
(such as IMPORT or EXPORT) and the HOST_ID.
Commandline syntax: RNET Operation HOST_ID [Param1 Param2]
Operation must be one of: EXPORT IMPORT SET TOP.
HOST_ID is *required* for all operations. HOST_ID is specified for what
configuration, QWK, and REP packet filenames to look for and should not
contain an extension. You should contact your Host Sysop to find out what
the HOST_ID is for your host's system. Examples of HOST_ID include FTL,
TRP, EXECNET, CHEERS, HIGHER, and SEMWARE.
Param1 and Param2 are used to specify additional information relating to
the operation being executed. Param1, for example, is used to specify the
conference to use for SET and TOP operations. See the text under each
operation for specific usage.
If you neglect to specify an operation RNet will display a help screen to
remind you of the syntax. On this screen you will see the copyright
notice, current version number, credits to Sysops who were helpful in
implementing or testing that version, and the Alpha, beta, registered, or
unregistered status.
RNET.DOC Page 9
___________________________________EXPORT__________________________________
Syntax: RNET EXPORT HOST_ID [ONLY LocalConf#]
Export instructs RNet to scan your messagebases for new outgoing messages
to be sent to your host. Any new messages found will be placed in a
compressed HOST_ID.REP packet (appending or overwriting, depending on the
instructions in the HOST_ID.CFG configuration). You would normally execute
this operation before calling your host for mail.
If needed, you may specify ONLY and a local conference number which will
export new messages in the specified conference _only_.
Examples:
RNET EXPORT CHEERS ;Export new messages for host CHEERS!
RNET EXPORT TRP ;Export new messages for host TRP
RNET EXPORT TRP ONLY 5 ;Export only new messages in local conference 5
___________________________________IMPORT__________________________________
Syntax: RNET IMPORT HOST_ID [ONLY|SKIPTO LocalConf#]
Import is used to insert new messages from a QWK packet into your local
messagebases. RNet will uncompress the HOST_ID.QWK packet(s), verify
NetStatus, and import the messages it finds. You would normally execute
this operation after having downloaded mail from the host.
There are two optional Param1 specifications accepted for the import
operation: ONLY and SKIPTO. If either of these are specified you must also
specify a local conference number (Param2).
ONLY allows you to import host messages in a specified conference. This is
very useful for recovering from problems such as a disk full condition or
similar disaster.
SKIPTO allows you to import host messages in conferences beyond a specified
local conference. This is very useful for continuing an aborted import.
Simply look at the log to find the last imported conference then use that
local conference number as Param2. RNet will then "pick up where it left
off" and continue importing host messages.
Examples:
RNET IMPORT CHEERS ;Import messages from host CHEERS!
RNET IMPORT TRP ;Import messages from host TRP
RNET IMPORT TRP ONLY 5 ;Import messages destined for conference 5
RNET IMPORT TRP SKIPTO 5 ;Resume aborted import at conference 5
RNET.DOC Page 10
____________________________________SET____________________________________
Syntax: RNET SET HOST_ID LocalConf# PointerValue
RNET SET HOST_ID LocalConf# MessagesFromTop
Though the host pointer file can be edited with a standard text editor
(such as QEdit or Edlin), you may change a messagebase pointer with the
commandline SET operation. Specify Param1 as the local conference number
to change, Param2 as the value to change the pointer to. If Param2 is
below the lowest numbered message, the lowest message will be used. If
Param2 is above the highest message, the highest message number will be
used. And finally, if Param2 is a negative value, RNet will use that value
subtracted from the highest (top) message number.
Examples:
RNET SET FTL 10 99999 ;set conf 10 pointer to high message.
RNET SET FTL 10 1 ;set conf 10 pointer to low message.
RNET SET FTL 10 -100 ;set conf 10 pointer to 100 from the top.
____________________________________TOP____________________________________
This works very similarly to the SET operation but has the advantage of
allowing you to change all the messagebase pointers at once. If Param1 is
specified as a local conference number, RNet will reset that conference
pointer to the high message in that messagebase. If Param1 is "ALL", RNet
will reset all conference pointers to the high message in each messagebase.
Examples:
RNET TOP TRP 1 ;set conf 1 pointer to last (top) message.
RNET TOP TRP ALL ;set ALL conf pointers to top.
RNET.DOC Page 11
___________________________Environment Variables___________________________
RNet will look for and make use of the following environment variables.
Note that none of these environment variables are required, but are simply
searched for and used if RNet cannot find what it needs elsewhere.
RNET= Specify the D:\DIR\ where RNet should search for the HOST_ID.CFG
file. RNet will first search the default (current) directory.
To maintain some compatibility with the old QNet 1.xx system,
RNet will look for the QWIKMAIL= environment if the RNET=
environment is not found.
Example: SET RNET=D:\PCB\RNET\
RNETCONF= Specify the complete D:\DIR\FILENAME that RNet should use for
its needed conference information (about your board). If a
filename is not specified, RNet will use the RNETCONF= value as
a base drive/directory and search for RNETCONF there. By
default, RNet looks for the file RNETCONF in the current
directory. Use the RNETCONF= environment if you want RNet to
look elsewhere and/or if you want it to use a different filename
for RNETCONF.
Example: SET RNETCONF=D:\PCB\RNET\
or SET RNETCONF=D:\PCB\RNET\RNETCONF.2
TMP= Specify the D:\DIR\ where RNet should place working files (such
as the uncompressed QWK and REP packets). The drive specified
must have enough space to handle your largest packet. RNet will
also look for the TEMP= and QWORKDIR= environment variables, in
that order. Note that the HOST_ID configuration keyword
WORKDIR= takes priority over the environment. If you wish to
have RNet use one of these environment variables, neglect to put
WORKDIR= in the HOST_ID.CFG file.
Example: SET TMP=Z:\SCRATCH99\
NODE= The NODE= environment is used to tell RNet what node number it
is running on so that it can correctly update NODE CHAT and
CALLERS log. The value must be from 0 to 99. If NODE= is
specified in the HOST_ID.CFG, it takes precedence over the NODE=
environment.
Example: SET NODE=1
RNET.DOC Page 12
____________________________Configuration Files____________________________
For every host you will be echoing from you will need to create a
configuration [HOST_ID.CFG] file. You may create as many CFG files as
desired or even multiple CFG files for each host.
A CFG file is a simple ASCII text file listing keywords and information.
RNet will parse the HOST_ID.CFG file (HOST_ID being what was given on the
commandline that specifies the net name of your host system) to get the
information it needs.
RNet will first check the default directory, then look for a RNET=
environment variable (specifying a drive:\directory path) to try to find
the HOST_ID.CFG file. If it fails to find the CFG file, RNet will abort
operation reporting "[host] Configuration file not found!"
Configuration files can and should be created with a standard text editor
such as QEdit or even Edlin. Blank lines and lines beginning with a
semi-colon (";") will be ignored. Each keyword should be specified on a
separate line and should have no trailing spaces between the keyword itself
and an equals ("=") sign that should follow. Please see the example CFG
files included in this ZIP file for a template to use.
In a future version a Configuration program will be included to ease the
configuration process. Meanwhile, it is recommended that you use an
existing template (example) CFG file to work with -- simply use the DOS
COPY command to copy/rename a SAMPLE?.CFG to the needed HOST_ID.CFG
configuration file.
Most keywords have synonym words (SYN) listed in the description. These
alternate keywords have the same meaning as the base keyword and may be
used interchangably.
The minimum keywords needed for any configuration file:
HOSTSYSOP (the host sysop name)
SYSOP (your name)
HOSTORIGIN (host system tagline) [or HTAG0]
ORIGIN (your system tagline) [or TAG0]
CONF (one per conference being echoed) [or CONVERT]
Highly recommended to be included in any configuration file:
REPLYPROCESS (so you know exactly what to expect)
WORKDIR (or allow environment to specify)
NODE (or allow environment to specify)
USERNET (even if only specifying "NONE")
You might do well using the example HOST_ID.CFG file as a base for creating
your configuration files. Simply copy or rename the HOST_ID.CFG file to
the proper name for your host (replace HOST_ID with the node/netname of the
host maildoor, such as FTL or TRP, or EXECNET), then edit the file as
needed. Remove any excess CONF statements to avoid exporting messages into
the wrong conferences!
RNET.DOC Page 13
_________________________Keywords: Names and Users_________________________
HOSTSYSOP Actual name of your host sysop. This is the name that
incoming messages addressed to/from "SYSOP" on your host
systems board will be translated into.
SYN: HOST_SYSOP
SYSOP Your name. Messages addressed to/from "SYSOP" on your system
will be translated into this name for outgoing messages.
SYN: LOCAL_SYSOP LOCALSYSOP
MAKESYSOP YES|NO; Should RNet address incoming mail to "SYSOP"? If you
specify YES to this keyword, RNet will translate any incoming
messages addressed to/from your name into "SYSOP."
SYN: MAKE_SYSOP
PRIVATEUSER Up to 25 users may be specified as "private mail users". Any
users specified by a PRIVATEUSER= entry in the CFG file will
be allowed to send private (R/O) messages despite the global
PRIVATE= setting. Useful for moderators, hosts, net sysops,
and administration folks to send private messages up the
network. Note that this does not change the settings of your
host's mail door -- private messages sent from the host are
controlled by the host.
SYN: PRIVATE_USER SPECIAL_USER PRIVATE_MAIL SPECIALUSER
Example: PRIVATEUSER=GEORGE CARLIN
TCAN You may specify up to 25 names (one full name per line) which
RNet should refuse to process. Any message addressed to/from
this user will not be imported or exported but instead written
to TCAN.LOG in the current directory.
SYN: TRASHCAN TRASH BADUSER BAD_USER
TOCAN You may specify up to 10 names with the TOCAN keyword (one
name per occurrence of TOCAN in the CFG file). If a message
is addressed TO this name, RNet will refuse to import/export
it. As with TCAN, the refused messages are written to TCAN.LOG
for your review.
SYN: TRASHCAN_TO TO_TCAN
FRCAN The same as TOCAN except checks the name against the FROM
field for each message instead of the TO field.
SYN: TRANSHCAN_FROM FROMTCAN FROM_TCAN
RNET.DOC Page 14
HANDLE Up to 50 handle/alias translations may be specified. This
keyword allows translation of the user name in the TO/FROM
fields in two ways. Because there are two forms for this
keyword it has confused folks in the past. Hopefully, these
explanations and examples will help.
Format: HANDLE=AlwaysFromThis,AlwaysToThis
Example: HANDLE=SPARKY,MARK HERRING
This example will translate "SPARKY" to "MARK HERRING".
*Everytime* "SPARKY" is seen in the to/from fields of a
message it will be changed into "MARK HERRING". The name
"SPARKY" will basically never appear locally or on the
network, as it will *always* be changed to "MARK HERRING".
During the name is changed to
--------- ------------- -------------
IMPORT SPARKY MARK HERRING
IMPORT MARK HERRING MARK HERRING
EXPORT SPARKY MARK HERRING
EXPORT MARK HERRING MARK HERRING
The second method of name translation allows you to change a
name one way during import and the other during export. Thus,
you can specify how a name appears on your board which is
different from the way it appears over the network. Note the
addition of the asterisk in the following example:
Format: HANDLE=*ExportAsThis,ImportAsThis
Example: HANDLE=*SPARKY,MARK HERRING
The asterisk is used to signify that you wish the
translation to "reverse" when doing an export. Anytime
the name "SPARKY" or "MARK HERRING" is seen during an
import, it is changed into "MARK HERRING". Anytime
"SPARKY" or "MARK HERRING" is seen during an export it is
instead changed into "SPARKY".
During the name is changed to
--------- ------------- -------------
IMPORT SPARKY MARK HERRING
IMPORT MARK HERRING MARK HERRING
EXPORT SPARKY SPARKY
EXPORT MARK HERRING SPARKY
Thus the name "SPARKY" will always appear over the network
while the name "MARK HERRING" will always appear on your
board.
Use HANDLE=Name1,Name2 when you *always* want 'Name1' to
be changed into 'Name2'.
Use HANDLE=*Name1,Name2 when you want 'Name1' to appear
on the network and 'Name2' to appear on your board.
SYN: ALIAS NAME_CHANGE
RNET.DOC Page 15
_____________________________Keywords: Taglines____________________________
Taglines are always forced into a standard format. Before the first
tagline that is to appear on a message, a tearline must appear. A tearline
is composed of a line with three dashes ("---") optionally followed by
additional text (FidoNet compatable method). All taglines follow this
tearline and begin with either " ■ " or " * ". RNet will automatically fix
taglines from other software packages that do not conform to this standard
and will remove blank lines from between taglines. RNet will automatically
chop off any taglines in excess of two.
HOSTORIGIN Use HOSTORIGIN to specify what tagline to place on messages
that originate from your HOST system. The host's mail door
does not place any taglines on messages, it is up to your end
of things. The tagline should conform to whatever network
standards are currently in effect. Note that the synonym
HTAG0 is commonly used instead of HOSTORIGIN.
SYN: HTAG0 HOST_ORIGIN HOST_TAG HOST_TAGLINE HOSTTAG
Example: HOSTORIGIN= ■ Host board name ■ City ■ Phone Number
HTAG0..9 The ten HTAGx statements allow you to specify up to ten
different host taglines. HTAG0 is the same as HOSTORIGIN and
may be used in place of it. To specify which of these ten
taglines is to be used as the host tagline on any given
conference, see the CONF statement below.
ORIGIN ORIGIN is used to specify the tagline to be placed on messages
coming from your system. All messages exported from your
system that originated from your system will have this tagline
placed on them. The tagline should conform to the network
standards of the network in question.
SYN: TAG0 TAGLINE LOCALTAG LOCAL_TAG
Example: ORIGIN= * BBS Name, City, Phone Number
TAG0..9 The ten TAGx keywords allow you to specify up to ten different
taglines for messages originating from your system. TAG0 is a
replacement for ORIGIN and can be used in place of it. To
specify which of these ten taglines are to be used for each
specific conference, see the CONF statement.
FORCETAG YES|NO. If you specify YES for this keyword, RNet will
*always* append a tagline (host or origin, as appropriate) on
all messages processed. Note that if the tagline addition
causes more than two taglines to be appended to the message,
any in excess of two will be stripped. This is used mostly
for forcing tagging of messages for debugging use.
SYN: FORCE_TAG FORCE
Default: NO (disabled; add tagline only when/if needed)
RNET.DOC Page 16
FORCENOTAG YES|NO. Specify YES to this keyword if you want to force RNet
*not* to append any taglines to any messages processed. In
smaller and in-company business echo networks, you might
desire to have no taglines.
SYN: NOTAG FORCE_NO_TAG
Default: NO (disabled; add tagline if needed)
RTAG YES|NO|ORIGIN. The RTAG keyword enables (YES) or disables
(NO) the " ■ RNet v.vvx: " on the beginning of each tagline.
If RTAG=ORIGIN is specified, RNet will use the Fido standard
" * ORIGIN: " at the beginning of the line and append ":RNet
v.vvx" to the end. Note that this keyword is subject to
different effects depending on the version/release of RNet:
Alpha/Beta: specifying NO changes the tagline id to a
shorter id (" ■ Rvvvx:"). This information is used for
beta debugging (watching) RNet operate over several large
networks where strict control is not possible.
Unregistered: RTAG=YES and RTAG=NO have no effect.
Registered: specifying RTAG=NO will completely remove the
" ■ RNet" part of the tagline. In this case, the text you
specify for host/origin (HTAGx and TAGx) taglines will be
the *complete* text used for the taglines.
SYN: RNETTAG RNET_TAG R_TAG
FIXJH YES|NO. This keyword tells RNet if it should automatically
decrypt encrypted John Hancock version 2.xx taglines. Some
networks do not allow encrypted taglines so this option allows
you to decrypt them automatically. If you specify FIXJH=YES,
both incoming and outgoing messages will be checked and
decrypted.
SYN: FIX_JH_TAGS
Default: NO (leave encrypted JH taglines alone)
________________________Keywords: Packet Processing________________________
COMPRESS Specify the program and options needed to compress a REP
packet for sending to your host. Check with your host about
what program/method should be used for packet compression
(most commonly PKZIP). All appropriate filenames will be
added to this command when RNet calls it, so only specify the
command and switches (if any) needed. NOTE: If the program
needed is not in the current directory or along the DOS PATH=
environment, specify the complete d:\dir\filename.ext.
SYN: PKPAK ARC PAK PKZIP ZIP
Default: PKZIP -m -ex
RNET.DOC Page 17
UNCOMPRESS Specify the command (program) needed to uncompress an incoming
QWK packet from your host. Check with your host as to what
program is needed. The command must accept placing of a
directory specification on the end (last parameter) for RNet
to place the files in the work directory. If this does not
work correctly (ie, is not supported by the decompression
program), you will need to remove all references (CFG and
environment) to WORKDIR= so RNet uses the current directory.
SYN: PKUNPAK UNARC UNPAK PKUNZIP UNZIP
Default: PKUNZIP -o
WORKDIR Use WORKDIR to specify the drive/directory where RNet should
place scratch files and uncompressed QWK packets. If you have
a large enough RAM drive, specify that. When RNet is done
processing, it will only delete the files it created or
uncompressed, thus, you may even use the current directory
safely if desired.
Note that the drive/directory pointed to by WORKDIR must
already exist or RNet will report an error. A recommended
drive/directory would be the "play" or "scratch" directory
used by the processing node for up/download processing.
This setting (WORKDIR) overrides the TMP= environment.
REPLYPROCESS APPEND|OVERWRITE. Specify APPEND for this keyword if you want
RNet to append new outgoing messages to an existing REP
packet. This allows you to keep adding to the end of a REP
packet when your host has been busy.
*WARNING*: if you use this option, you must delete your
HOST_ID.REP packet after successful upload to your host.
Failure to do so will result in uploading duplicate messages!
SYN: REPLY_PROCESS
Default: Delete (overwrite) existing HOST_ID.REP packets.
ARCHIVE The only option for this keyword is EXTERNAL and should only
be specified if you are prepared to handle it. If you specify
ARCHIVE=EXTERNAL, RNet will not shell to DOS to execute the
COMPRESS and UNCOMPRESS commands, but will instead assume that
you are going to handle these functions before and after
calling RNet. If you are in a tight memory situation, you
will likely need to use this option. Please see LOWMEM.BAT
for more information and an example of how to handle
compression/decompression in this manner.
QWKPATH Specify the d:\dir\ where RNet should look for QWK packets
from your host. RNet will automatically process multiple
packets (HOST_ID.QW?) if found, in numerical order. You
should use this keyword to point to the download d:\dir\ that
your terminal communications program downloads QWK packets to.
SYN: QWK QWKS QWK_PATH QWKPACKETS QWK_PACKETS
Default: Current drive/directory
RNET.DOC Page 18
REPPATH Use this keyword to specify the d:\dir\ where RNet should
create HOST_ID.REP packets for sending to your host. Usually
this will be the d:\dir\ where your terminal program expects
to find files for uploading.
SYN: REPLOC REP_PATH REPDIR REP_DIR
Default: Current drive/directory
KILLQWK YES|NO. The KILLQWK keyword allows you to instruct RNet to
delete the HOST_ID.QWK packets after *successful* import. If
anything goes wrong or if RNet has reported any warnings, the
packet will NOT be deleted. This can be useful for your event
batch file to figure out if the import process proceeded
without any problems simply by looking for the existence of
*.QW? after import processing. If *.QW? exists, something
went wrong. If you do not use this option, be sure to
manually delete or move the packet before your next mailrun to
avoid inserting duplicate messages.
SYN: KILL_QWK DELETEQWK DELETE_QWK
Default: NO (QWK packets are not automatically deleted)
CHECKREP YES|NO. If you wish, RNet can check for, and prompt you for
what to do with an existing REP packet (during both IMPORT and
EXPORT setup operations) when it finds one. Specify
CHECKREP=YES to have RNet look for any existing REP packets,
and if one exists, prompt you to: Delete the packet and
continue; Retain the packet and abort operation; Continue
normally (default). RNet will wait for 10 seconds for you to
make a decision. This option is available so that if you do
manual processing of a mailrun, you will be prompted about the
disposition of any existing REP packets that you may have
forgotten to manually delete.
SYN: CHECK_REP
Default: NO (do not prompt operator for REP disposition)
CKPOINTERS YES|NO. By default, RNet will automatically check all its
current pointers against the existing messagebases (which can
take a minute or two if you have 2000+ echo conferences). If
it finds a problem, it will automatically correct the pointer
file. Pointers are checked against the current High and Low
message numbers in the conference messagebase to determine
that the pointer is valid. You may specify CKPOINTERS=NO to
disable this safety feature (this is *not* recommended!).
SYN: CHECKPOINTERS CHECK_POINTERS
Default: YES (check all pointers every time RNet is run)
RNET.DOC Page 19
_________________________Keywords: Message Handling________________________
PRIVATE YES|NO. This is a global specification as to if private (R/O)
messages are allowed on the network in question. If the
network you are connecting to allows *all* users in *all*
conferences to send private (R/O) messages, specify
PRIVATE=YES. Note that RNet will honor the PCBoard/ProDoor
conference configuration (PCBSETUP/PROSM) which specifies that
all messages should be private (R/O) regardless of this
keyword setting. Use PRIVATE=NO and PRIVATECONF (see below)
to specify private messages are allowed only in specific
conferences.
SYN: SENDPRIVATE SEND_PRIVATE
Default: NO (send only public messages)
COMMENTS YES|NO. This keyword specifies if Sysop COMMENT security
messages should be exported. This is useful if you are
running multiple BBS's and want to send all messages from one
system to another via RNet. Note that PRIVATE must be
specified YES as well for this option to be in effect.
SYN: SENDCOMMENTS SEND_COMMENTS
Default: NO (do not send COMMENT security messages)
PRIVATECONF You may specify a list of local conference numbers (separated
by commas) in which private messages are permitted to be
transmitted. This option is added such that you may have a
network which only allows private (R/O) messages in certain
conferences. You may specify as many PRIVATECONF statements
as needed or desired. Note that using PRIVATE=YES is the
global of this keyword.
SYN: PRIVATE_CONF
Example: PRIVATECONF=1,10,11,12,200,201
IGNOREECHO As with PRIVATECONF, you may specify a list of conferences
(ie, by local conference number) in which you want to ignore
the PCBoard 14.x EchoFlag status. This is useful if you have
an automated process or another mail package that turns off
the EchoFlag for some reason and you want to export the
messages despite the EchoFlag. Normally, RNet will not export
messages that do not have the EchoFlag specifically enabled on
them.
SYN: IGNORE_ECHO
Example: IGNOREECHO=5,6,7,10,11,12,200,201
ANSICONF This keyword is used to enable ANSI escape sequences in any
given conference(s). List conferences by local conference
number (as with IGNOREECHO above). RNet will "fix" translated
(filtered) ANSI sequences when it can in these conferences.
SYN: ANSI ACCEPT_ANSI
RNET.DOC Page 20
KEYCODE KEYCODE is used to support multiple or cross echoed networks
within the same conferences. KEYCODE specifies a single
character, preferably one of !, @, #, $, %, ^, &, or a single
alphanumeric character, which is to be used to specify the
network of origin of a message.
If you are only echoing a single network or if you are not
involved in cross echoing of multiple networks into the same
conferences (ie, not a 'gateway'), simply specify KEYCODE=! or
something similar (DO NOT USE "*") and ignore the rest of this
description.
Specify a different KEYCODE for each network you will be
echoing. For example, if echoing ILink, you might specify
KEYCODE=I, and for CanConfMail, specify KEYCODE=C. Doing
this, if you echo both networks into the same physical
conference, messages from either network will be sent out to
the other automatically (along with all replies and messages
coming from "lower" on the networks). This is known as a
'Gateway' connection.
If you wish to import multiple networks into the same
conference and do not want to send the messages from one
network to the other, specify the same KEYCODE for both
networks (such as KEYCODE=! for in both configurations). In
this case (both KEYCODEs being the same), messages from one
network host will *not* be sent to the other while all
messages originating from your board (or lower on the
network(s)) *will* be exported to both network hosts. Not
likely desired or needed, but the ability is there.
Basic logic description: All messages imported will have the
defined KEYCODE assigned to them. During export processing,
any messages that have the exact KEYCODE on them will not be
exported (thus avoiding bouncing messages back up the net).
Messages sent up to your board from lower on the network will
always have a keycode of "*". If you did not want to send
messages from lower on the network up the network (who knows
why you would want to do this?!), specify a KEYCODE of "*".
SYN: BBSKEY BBS_KEY BBS_KEYCODE
Example: KEYCODE=!
___________________________Keywords: Conferences___________________________
CONF You must specify one CONF statement for every echo conference
you are intending to echo with your host. The CONF keyword is
used to specify how your local conference numbers correspond
to the host's conference numbers. You may also use it to
specify an alternate tagline to be used for each conference
(see HTAG0..9 and TAG0..9 above). Commonly, the synonym
CONVERT is used for CONF.
Format: CONF=Local#,Host#:Tag#
Note that the ":Tag#" part of the CONF statement is optional
RNET.DOC Page 21
and only needed if you wish to specify using taglines other
than HTAG0 and TAG0 (see HTAG0..9 above).
You may place "comments" after the CONF statement (avoid using
a ":" in the comment!) such as listing the conference name.
The examples below are valid as they are. See also the
SAMPLE?.CFG files.
SYN: CONVERT CONFERENCE
Example: CONF=1,55 (my 1 = host 55, use H/TAG0 tags)
Example: CONF=2,56:0 (my 2 = host 56, use H/TAG0 tags)
Example: CONF=3,60:1 (my 3 = host 60, use H/TAG1 tags)
Example: CONF=4,61:1 (my 4 = host 61, use H/TAG1 tags)
Example: CONF=5,62:1 (Sysops Echo)
_____________________________Keywords: NetNews_____________________________
NetNews keywords are used to allow a network to support a special "NetNews"
type conference that has only special news messages from the network
administration. The philosophy behind the RNet NetNews conference support
is to create a conference that is not echoed, but instead has messages
inserted in it that come from another conference. The messages inserted
into this special NetNews conference are designated by key words and users
as defined by the following keywords. Ask your network administration if
this form of NetNews conference support is available and/or simply monitor
the administration conferences and figure out for yourself what "special"
messages should be extracted into a special conference (presumably, public
for all users to read).
All messages imported/exported in the NETADMIN conference are checked. Any
message that is addressed to ALL, addressed from NETADMIN, and the subject
contains the text specified by NETSUBJECT, will be copied to the NETNEWS
conference as public and non-echo.
NETNEWS Specify the local conference (by number) to be used as the
destination for NetNews type messages. Messages which match
the parameters specified by the other keywords will be copied
into this conference. This will commonly NOT be an echo
conference and usually has the "Make all messages private"
option turned on in PCBSM/PROSM. RNet will insert messages
here as public (despite the "Make private" setting).
SYN: NET_NEWS NET_NEWS_CONF
Example: NETNEWS=15 (use local conference 15 for NetNews)
NETADMIN Specify a local conference number that is normally used for
Administration level messages. This conference will be
checked during processing for messages that match NETADMINID
and NETSUBJECT. Messages which match the requirements will be
copied to the NETNEWS conference. The original messages will
still be imported/exported in this conference so that it is
passed to other systems up and down the network.
SYN: NET_ADMIN NET_ADMIN_CONF
Example: NETADMIN=44 (search conf 44 for NetNews messages)
RNET.DOC Page 22
NETADMINID Use this keyword to specify the name that a message must be
FROM to qualify as a NetNews message. Usually this is either
a special alias (such as "Network Administration") or someone
in the administration. The message in question must also be
addressed to "ALL" to qualify -- this keeps replies and other
comments from appearing in the NetNews conference.
SYN: NET_ADMIN_ID NETADMIN_NAME NET_ADMIN_NAME
Example: NETADMINID=NETWORK ADMINISTRATION
NETSUBJECT Messages in the NETADMIN conference are checked, and assuming
the message matches the NETADMINID the NETSUBJECT is checked.
Specify a key phrase or word that must appear in the subject
of the message to qualify as a NetNews message. Usually this
is something along the lines of "** ANNOUNCEMENT **". The
subject need not match exactly, but must contain the phrase or
words specified with this keyword (which is *not* case
sensitive).
SYN: NET_SUBJECT
Example: NETSUBJECT=** ANNOUNCEMENT **
Logic example: Using the examples above, if a message appears in local
conference 44 (either during import or export processing, so it works even
when the message is going "up" the network) is addressed to "ALL", is from
"NETWORK ADMINISTRATION" and has the text "** ANNOUNCEMENT **", that
message will be copied to local conference 14 as public and non-echo.
________________________Keywords: Multinode/NodeChat_______________________
If you are running a multinode system concurrently with your RNet event
processing (which is perfectly safe, by the way), you should specify the
following keywords to help RNet determine how to proceed. RNet honors and
will check the PCBoard messagebase LOCKED field when inserting messages in
all cases. Assuming you specify these keywords correctly, you may "watch"
RNet processing via the NODE CHAT display.
NODE This keyword, when used, will override the environment
variable NODE. If you specify a value of 1-99, RNet will
"login" to that node as far as the Node Chat and CALLERS logs'
are concerned (see CALLERLOG below). Specify a value of 0 and
USERNET=NONE if running a single node system. Specify a value
of 0 and correctly specify USERNET=d:\dir\usernet.dat to have
RNet use the NODE= environment.
SYN: PCB_NODE NODE_NUMBER PCBNODE NODENUMBER
Example: NODE=3 (mail events are processed by node 3)
USERNET Specify the d:\dir\filename.ext of the PCBoard node chat
USERNET.DAT file. RNet will show up as a node on the Node
Chat display reporting exactly what it is doing (Init,
Exporting xxx, Importing xxx, Cleanup, etc) via the city/state
field. RNet must have this keyword specified correctly for
its automatic speed selection from fast/slow. If RNet sees a
user on another node who is: Unavailable, Entering a message,
or Out of code in door, then RNet will use a slow (safer)
RNET.DOC Page 23
concurrent message entry routine. If all users are Available
or doing other things, RNet will use a faster insertion
routine (it will not flush the directory structure between
each message).
If running a single node system specify USERNET=NONE.
SYN: NETUSER NETUSERS NETDATA NETINFO
Example: USERNET=D:\PCB\MAIN\USERNET.DAT
_____________________________Keywords: Reports_____________________________
CONFREPORT Specify the complete d:\dir\filename.ext that RNet should
write the conference analysis report to. This report shows
each configured conference, number of messages exported/
imported, locally created, percentages comparisons to traffic
locally and netwide. Very handy report to keep around!
SYN: CONF_REPORT REPORTFILE REPORT_FILE
Example: CONFREPORT=D:\PCB\GEN\BLT20
SUPERLOG If you want this report, specify a d:\dir\filename.ext for
this keyword. The SUPERLOG (aka ALLMESSAGELOG), is a listing
of every message imported or exported by conference, message
number, subject, date, addressed to and from. This log can
quickly eat up valuable disk space (similar to the way a
CALLERS log can), so don't let it sit around without attention
too long.
SYN: ALLMESSAGELOG
Example: SUPERLOG=D:\PCB\GEN\ALLMSGS.LOG
DAILY YES|NO. Enable or disable the daily report analysis logging.
RNet will normally create a log report listing each conference
and the number of imported/exported messages. These reports
are automatically maintained for the last six days based on
the day of the week. The files created are in the default
directory named VERBOSE.XXX where XXX is the day of the week
(such as SUN, MON, TUE). RNet always deletes "tomorrow's"
report so that the reports do not consume excess drive space.
Specify NO if you want to disable this reporting function.
SYN: DAILYLOG DAILY_LOG
CALLERLOG If you want RNet to report the number of messages imported and
exported in each conference to the CALLERS log, use CALLERLOG
to specify the d:\dir\filename.ext for your CALLERS log file.
If you are running a multinode system, do NOT include the node
number on the end of the file as RNet will automatically
append this. If running a single node system (ie, NODE=0),
RNet will not append a node number to the filename. RNet will
report itself logging in, a baud rate of (Event), Graphics on,
and IMPORT or EXPORT for the city/state field. Next, it will
list each conference that has at least one message of traffic
in it and the total number of messages imported or exported.
Finally, RNet will report the number of minutes used and
logoff "normally" (if that is the case).
SYN: CALLER_LOG CALLERS
RNET.DOC Page 24
Example: CALLERLOG=D:\PCB\MAIN\CALLERS
LONGCALLER YES|NO. If you specify YES for this keyword, the CALLERLOG
report will be much more verbose. The LONGCALLER report lists
every message imported/exported as if a "user" had left the
messages in the first place. This can be useful for caller
analysis programs to know exactly how much message traffic is
occuring in each conference.
SYN: VERBOSECALLERLOG VERBOSE_CALLER_LOG LONG_CALLER_LOG
Default: NO (use the short callerlog report format)
____________________________Keywords: Additional___________________________
EXTENDED YES|NO. This keyword is used to clarify to RNet if your host
is using or supporting more than 255 conferences. This may or
may not be needed depending on the mail door you are using on
your host. If you are using MarkMail 2.xx or KMail with
conferences numbered higher than 255 on your host (your local
conference numbers are not important), you may need to specify
EXTENDED=YES to be sure RNet understands. RNet should be able
to determine this for itself, but since there is no agreed-to
standard, RNet may need some help figuring it out.
SYN: EXTENDED_CONFS EXTENDEDCONFS
RUN You may specify as many RUN statements in your configuration
file as desired. When RNet encounters the RUN keyword in the
configuration file, it takes the text following the equals
sign and executes a DOS COMMAND.COM/C shell with the command
specified. This is useful if you want to be sure RNet does
something every time it is run without having to remember to
run a batch file to access RNet. A common use is to force
RNEt to update its RNETCONF file with any changes to your
conference setup since the last time it ran.
Example: RUN=PCBCONF d:\pcb\main\cnames -i
Example: RUN=IF EXIST *.QW? COPY *.QW? D:\HOLDQWKS
Example: RUN=MD S:\WORK
RNET.DOC Page 25
____________________________Initial Installation___________________________
[This assumes that you have already arranged NetStatus with your host BBS
and is the most common setup design folks use for RNet. Additional steps
(such as step 5) are added to account for differing situations.]
1. Create a directory for RNet. Copy all the files from the distribution
ZIP into this directory. Later, you can delete any files you don't
need or want (such as the SAMPLE?.CFG files).
2. Run either PCBCONF.EXE or PROCONF.EXE to create the RNETCONF file --
RNet will not operate without this file being created. If running
PCBoard 14.x, use PCBCONF. If running ProDoor 2.9+, use PROCONF.
Syntax: PCBCONF D:\DIR\CNAMES
Syntax: PROCONF D:\DIR\CONFINFO
3. Use a text editor such as QEdit or Edlin to create a HOST_ID.CFG file.
If desired, use one of the SAMPLE?.CFG files as a starting point by
renaming or copying it to the appropriate HOST_ID.CFG name.
Example: FTL.CFG (Faster-Than-Light BBS as host)
Example: TRP.CFG (The Right Place<tm> BBS as host)
Example: EXECNET.CFG (Executive Network BBS as host)
See the documentation above for more information on HOST_ID.CFG files.
4. Run RNet to create a pointer file. RNet will automatically check
the pointers against the messagebases after the pointer file is
created. The TOP operation is selected in case you have another
utility you have been using for echomail so that messages will not be
lost (see step 5).
Syntax: RNET TOP HOST_ID
5. If you were previously running another echomail utility, run it one
last time to export any messages which need to be exported. This is
done _after_ step 4 so that any messages entered on another node
between steps 4 and 5 will not be lost.
If you were previously running QNet or another QWK packet echomail
package, place the newly created REP (if there is one) where you have
instructed RNet to look for/create REPs. Commonly, this is either the
RNet directory or the directory where your terminal program expects to
find files for uploading. Assuming you have RNet set to APPEND to
REPs (default configuration), RNet will append any new outgoing
messages to this REP the next time you run an EXPORT.
If you were previously running a non-QWK compatible echomail package,
you should upload/send/do-whatever-is-needed the file up to your host
-- it might be convenient to do this while handling step 6.
6. Call the host system and configure the mail door. Open the mail door
you will be using for your echomail transfers. Configure the mail
door for the conferences you will be transferring -- set all pointers
as appropriate, usually by "topping" all conferences.
RNET.DOC Page 26
If you were previously using a QWK packet system, you probably need
change nothing. If you have a REP file for upload, you should upload
it now. (If you do upload it, don't forget to delete it!)
7. Download a QWK packet. You might want to change the pointers on all
of the conferences you will be echoing such that you get SOMETHING in
every conference. In other words, set the pointer for each conference
to one less than the high message number. This should result in you
getting one message per conference. Download the QWK to the directory
where you have told RNet to expect to find QWK's.
8. Logoff the host, go back to the RNet directory and execute a RNET
IMPORT HOST_ID -- this assumes that you did get a QWK packet while in
the mail door. Watch the operation to be sure that nothing is wrong
(conferences go where they should, work directory exists, etc). Make
any changes to the HOST_ID.CFG as needed. After successful IMPORT of
the QWK packet, be sure to delete it (if you have KILLQWK=NO).
9. Setup an automated method (suggested) of transferring the mail.
Usually this is done via EVENT.SYS and a communications program script
or perhaps a package such as RoboComm.
10. If you have any questions or problems, you host will probably have the
quickest answers and can help. If RNet refuses to run or has a
problem, it will report (both to the screen and to an ERROR.LOG file)
where it is having difficulties. Check drive & directory entries
carefully, as they are the most common problem causing elements.
If RNet says: "NetStatus Not Enabled", try adding EXTENDED=YES to your
CFG file. If it still says "NetStatus Not Enabled", you need to call
your host to enable NetStatus (some doors don't "believe" the NetStatus
until told a couple times... sheesh).
RNET.DOC Page 27
_________________________Copyrights and Trademarks_________________________
All programs mentioned are copyrighted and/or trademarked by their
respective holders. Please refer to each respective program to determine
the actual copyright/trademark holder as appropriate or needed.
______________________________Acknowledgments______________________________
Roger Sligar -- Sysop of The Right Place<tm> in Atlanta. He gets top
billing around here for all his support/prodding/effort and
uncountable hours of chasing down bugs/messages across the
world! It was the desire to safely and dependably run a
couple echo's with TRP that was the invention of RNet.
Mark Herring -- Inventor of the QWK format and offline readers/maildoors.
Without his original ideas to bring offline readers to the
PCBoard market, RNet would never have existed.
ILink -- (formally InterLink). A good international network of good
folks who very quickly adopted RNet into wide use. It is
for the continued growth of networks like ILink that RNet
is constantly being improved.
... and to the many registered Sysops who are running RNet! -- Thank you for
your support and as always, please let me know of any ideas or suggestions
you have! I hope you and your users enjoy the wild and wonderful world of
EchoConferences!